Release 10.1A: OpenEdge Development:
Progress 4GL Handbook

Making sure you release record locks

Under no circumstances do you want to hold a record lock longer than you need it. The best way to make sure you get the locking you want is to be explicit about it. Do not fall back on Progress defaults, which try to give you reasonable behavior when you don’t specify the behavior you want, but which cannot always anticipate what your procedure really requires. Here are two guidelines for using locks:

Never read a record before a transaction starts, even with NO-LOCK, if you are going to update it inside the transaction. If you read a record with NO-LOCK before a transaction starts and then read the same record with EXCLUSIVE-LOCK within the transaction, the lock is automatically downgraded to a SHARE-LOCK when the transaction ends. Progress does not automatically return you to NO-LOCK status.
If you have any doubt at all about when a record goes out of scope or when a lock is released, release the record explicitly when you are done updating it with the RELEASE statement. If you release the record, you know that it is no longer locked, and that you cannot unwittingly have a reference to it after the transaction block that would extend the scope of the lock, or even the transaction.

If you observe these two simple guidelines, your programming will be greatly simplified and much more reliable. Here are a few rules that you simply don’t need to worry about if you acquire records only within a transaction and always release them when you’re done:

A SHARE-LOCK is held until the end of the transaction or the record release, whichever is later. If you avoid SHARE-LOCKs and always release records when you’re done updating them, the scary phrase whichever is later does not apply to your procedure.
An EXCLUSIVE-LOCK is held until transaction end and then converted to a SHARE-LOCK if the record scope is larger than the transaction and the record is still active in any buffer. Again, releasing the record assures you that the use of the record in the transaction does not conflict with a separate use of the same record outside the transaction.
When Progress backs out a transaction, it releases locks acquired within a transaction or changes them to SHARE-LOCK if it locked the records prior to the transaction. If you don’t acquire locks or even records outside a transaction, you don’t need to worry about this special case.